One
of the new features that received close attention in Windows Server
2008 was a new breed of domain controllers referred to as Read-Only
Domain Controllers, also known as RODCs. The RODC hosts a copy of the
Active Directory (AD) database like any other writable domain
controller, but as its name implies, the contents replica of the domain
database residing on the domain controller is read-only and write
operations are not supported. It is equally important to mention that
the RODCs do not participate in Active Directory replication in the same
fashion as writable domain controllers. The fundamental difference
between RODC replication and the typical multimaster replication model
between writable domain controllers is that RODC replication is
unidirectional. This means all changes from a writable domain controller
are propagated to the RODCs. As a result, the RODC receives changes,
but does not partake in or perform outbound replication with other
domain controllers. This characteristic of RODCs provides an extra layer
of security as any unauthorized data changes, especially changes made
with the intent to hurt the organization, will not replicate out to
other domain controllers. Unidirectional replication also reduces the
workload of bridgehead servers in the hub site and the effort required
to monitor replication.
Another new RODC
functionality that improves security is commonly witnessed when
replication transpires between a writable domain controller and an RODC.
Here, user account information is replicated, but account passwords are
not replicated. This is a new phenomenon because of the existence of
Windows domain controllers. Security is bolstered in this situation as
the only password that resides on the RODC is the local administrator’s
password and Krbtgt accounts (the account used for Kerberos
authentication). In essence, the read-only philosophy of an RODC is
similar to the NT 4.0 Backup Domain Controller (BDC); however, with the
NT 4.0 BDC, all user information is replicated from the Primary Domain
Controller (PDC), including passwords.
Note
If needed, it is also
possible to configure credential caching of passwords for a specific
user account to an RODC. Moreover, by default, security groups with high
privileges such as Domain Administrators and Enterprise Administrators
are configured to never allow their passwords to replicate to RODCs.
Although
Microsoft fields numerous questions on this new Active Directory
technology, the question that is asked the most is where does the RODC
fit in? RODCs are most often used to provide Active Directory Domain
Services (AD DS) to remote locations and branch offices where heightened
security is essential, where Windows Active Directory administrators
are lacking, and where the promise of physical security is practically
nonexistent. In many cases, RODCs offer a practical headache-free
solution for branch office environments that in the past had to endure
solutions that always put them in compromising situations.
Organizations’ Branch Office Concerns and Dilemmas
The next section
illustrates typical branch office concerns about having domain
controllers onsite. This section makes it evident why the RODC is
becoming popular if not extremely necessary for branch offices.
Lack of Physical Security at the Branch Office
Typically, branch office
locations do not have the facilities to host a data center. For that
reason, it is common to find domain controllers hiding in closets,
tucked away in the kitchen next to the fridge, or even in a restroom. As
such, branch offices lack physical security when it comes to storing
domain controllers, which results in these servers being prime targets
for thieves.
Domain Controllers Stolen from the Branch Office
With inadequate physical
security in the branch offices, it was very common for domain
controllers to be stolen. This posed a major security threat to
organizations because domain controllers contain a copy of all the user
accounts associated with the domain. Confidential items such as highly
privileged administrator accounts, DNS records, and the Active Directory
schema could fall into the hands of the wrong people in this situation.
Removing Domain Controllers from the Branch Office
Because of a lack of physical
security and concerns over domain controller theft, branch offices often
had their domain controllers removed from their site. After being
removed, users were forced to authenticate over the WAN to a domain
controller residing at their corporate headquarters or to the closest
hub site. Although this action solved the security issue, it also
cultivated a new problem. If the WAN link between the branch office and
hub site was unreliable or unavailable, users could not log on to the
workstations at the branch office or the amount of time required to log
on was greatly increased. This resulted in a loss of productivity for
users in the branch office or outages that resulted in downtime if the
WAN link was severed. These types of outages commonly lasted for days.
Lack of Administration Role Separation at the Branch Office
In small branch offices, it is
also very common for multiple server functions to be hosted on a single
server to reduce costs. For example, a single server might provide
domain controller, file, print, messaging, and other line-of-business
(LOB) functionality. In such cases, it is necessary for the
administrators of these applications to log on to the system to manage
their applications. By granting administrators privileges to the domain
controller, these individuals also received full access to the Active Directory domain, which is considered to be a major security risk.
Lack of IT Support Personnel at the Branch Office
It is very common for
secretaries, receptionists, or even high-level personnel such as
managers and directors without any prior knowledge of IT management or
maintenance to manage servers in a branch office. Typically, these
individuals get nominated or promoted to a branch office IT support role
because a local IT administrator does not exist. Unfortunately, even
when conducting basic administration tasks like restarting an
unresponsive server, these individuals can inadvertently wreak havoc on
the Active Directory domain when granted administrator privileges on a
domain controller. In a Windows Server 2003 environment, there was
little that could be done about this situation. You just had to be
careful about who you promoted to the exclusive club of domain
administrators.
